Создаем игры с нуля! 3 книги для старта в гейм-деве - Григорий Радовильский

В зависимости от уровня развития менеджмента в студии, задачи могут содержать всю необходимую для выполнения информацию или иметь только ссылки на документацию. В первом случае у менеджеров должна быть возможность легко выделить из документации всю необходимую для исполнителя информацию. Документации нужна строгая и удобная структура, с которой сможет работать менеджер, даже особо не разбирающийся в дизайне игр. А во втором случае документация должна быть поделена на обособленные блоки, в которых не будет содержаться ничего лишнего для конкретного исполнителя, и груз разделения документации ложится на плечи самого дизайнера игры.

Это разделение на блоки может проходить как внутри описания каждой отдельной игровой механики, так и на более высоком уровне. Мы можем перечислять все элементы, относящиеся к каждой отдельной фиче внутри нее, и объединять описания отдельных аспектов всех фичей в большие разделы, например посвященные всем функциональным описаниям, всем интерфейсам, всем персонажам и т. п.

Первый вариант – сохранять иерархию внутри документа – может быть более удобен при ведении документации в файлах или облачных документах. Этот способ хорош для тех, кому по роли положено обладать полной информацией о фичах, например для тестировщиков или тех, кто будет собирать интерфейсы.

Второй вариант – большие разделы – скорее всего, будет удобнее при использовании сервисов ведения документации. Этот метод подойдет для специалистов в конкретных областях. Например, дизайнеру интерфейсов комфортнее иметь собственный раздел в документации и работать в нем.

Но однозначного ответа и строгих правил тут нет. Если у студии нет уже сложившихся правил, то они будут выработаны на этапе прототипирования. Основными правилами ведения документации является удобство для тех, кто ее ведет, и понятность для тех, кто будет ей следовать.

Инструменты

Для разработки даже небольшой игры может понадобиться достаточное количество различных инструментов. И современный мир встречает даже неопытного разработчика с распростертыми объятиями, стараясь облегчить ему жизнь настолько, насколько это возможно. Инструменты есть практически для всего, и единственное, чего они не могут, – это сами придумать и реализовать игру.

ИНСТРУМЕНТЫ ДЛЯ ДОКУМЕНТАЦИИ

Так как мы рассматриваем разработку игр именно с точки зрения игрового дизайна, то начнем с главного для любого гейм-дизайнера инструмента: текстового редактора.

Для работы с текстами есть три инструмента разной сложности и распространенности.

• Программы типа Word, входящего в пакет MS Office, и его аналоги для работы с файлами, хранящимися на компьютере. Этого вполне достаточно при работе над игрой в одиночку, но надо помнить, что хранить файлы на компьютере небезопасно. Компьютер может сломаться и уничтожить труд всей жизни. Документация игры – это сложная структура, описывающая множество переплетенных друг с другом объектов, и работать с этой структурой в рамках одного или нескольких отдельных файлов может быть не очень комфортно.

• Сервисы типа Office 365 и Google Drive позволяют работать с файлами онлайн. Это удобно для работы в небольшой команде и позволяет иметь доступ к файлам в любое время с любого устройства, а также безопасно по сравнению с хранением файлов на своем компьютере. Но это также несет некоторые риски: требует подключения к интернету и ставит в зависимость от аккаунта в сервисе, который может стать по тем или иным причинам недоступным.

• Бизнес-приложения, предназначенные для отдельного ведения документации, или являющиеся частью более сложного комплекса сервисов. К первым относятся такие сервисы, как Notion и Confluence, – эти сервисы позволяют вести документацию в структуре, похожей на «Википедию». Есть также бесплатные сервисы для этого. Подобная структура значительно удобнее работы с отдельными файлами. Она позволяет создавать автоматические шаблоны разделов и ссылки внутри документов, а также часто имеет более глубокую интеграцию с сервисами, предназначенными для менеджмента проектов.

• К более сложным комплексам относятся сервисы типа GitHub или Azure, которые предназначены скорее для работы с программным кодом, чем с документацией, но тем не менее позволяют эту документацию вести. К особым преимуществам бизнес-приложений относится совершенно другой уровень безопасности. Некоторые сервисы можно самостоятельно запустить на собственном сервере, например расположенном в офисе, ограничив доступ к данным компьютерами, находящимися в офисной сети.

Единственным серьезным недостатком бизнес-приложений является то, что они крайне редко имеют достаточно развитый редактор таблиц уровня Excel (для работы с локальными файлами) или Google Sheets (для работы с файлами онлайн). Без табличного редактора практически невозможно ни рассчитывать баланс, ни хранить характеристики предметов. К сожалению, из-за этого недостатка часто необходимо вести работу с несколькими различными программами и сервисами одновременно.

Очень важной частью работы над документацией является создание различных схем – визуализация алгоритмов. И для этих целей могут использоваться как встроенные в текстовый редактор инструменты рисования, так и внешние. В профессиональном пакете MS Office есть программа Visio, а в комплексе Google Drive доступен сервис Diagrams.net.

ИНСТРУМЕНТЫ ДЛЯ МЕНЕДЖМЕНТА

Системы менеджмента довольно тесно переплетены с сервисами ведения документации. Эти системы могут значительно отличаться по возможностям и целям.

• Trello – лишь один из множества, но необычайно популярный сервис для управления проектами по методике SCRUM или KANBAN. Он позволяет работать с доской, на которой можно наблюдать за статусом тех или иных задач, находящихся в разработке. Сама система Trello позволяет делать любые доски, распределяя задачи по приоритетности, типу, исполнителю и т. п.

• К более сложным системам относятся такие сервисы, как Asana и Jira. Они позволяют провести разделение на отдельные проекты внутри одного аккаунта, а также вести более сложную структуру работы с отдельными задачами. Начиная с объединения отдельных задач в группы пользовательских историй и фичей (например, задача создания монстра, для которой требуется работа дизайнера, художника и программиста) и заканчивая созданием собственных пайплайнов внутри сервиса (мы можем настроить автоматическую передачу задачи в тестирование при ее завершении или автоматическую передачу персонажа художнику по текстурам после завершения работы над моделью). В этом случае возможности контроля и автоматизации процессов на проекте практически бесконечны. Более того, Jira имеет прямую интеграцию с сервисом Confluence, так как они являются частью одной экосистемы.

При работе в компании есть сотрудник, ответственный за менеджмент проекта, но, если работать в одиночку, этим придется заниматься самостоятельно. Это необычайно сложно, ведь придется перенести все задачи из документации в отдельный сервис и поддерживать его в актуальном состоянии. Но в то же время это и необычайно важно – только так есть возможность объективно понимать, насколько проект готов и